Extending Microsoft Dynamics CRM 4.0 : IFrames

Form Events

Two events are global in nature for all forms: the onLoad event and the onSave event.

The onLoad event fires after the form has completed loading, and is commonly used to send an alert to the user, disable fields, or modify field values.

The onSave event fires when the Save or Save and Close buttons are accessed, and it is important to note that it fires regardless of whether data on the form has been changed. This event is commonly used to validate an entry because the onSave event can cancel the save operation.

In addition to the form events, the onChange event is available for every field on a CRM form. To fire the onChange event, the field that has the event attached to it must have its value changed, and it must lose the focus (by the user selecting or tabbing elsewhere on the form).

IFrames

One of the easiest ways to perform an integration to an existing Microsoft Dynamics CRM deployment (both hosted or On Premise) is to use IFrames.

IFrames are “inline frames or windowless inline floating frames” and provide an easy mechanism for integrating data, because they can exist free form or easily pass data through them to the underlying source.

To create an IFrame, open the Form Designer, select Add an IFrame, and complete the information required. Figure 1 shows the basic information of a sample IFrame.

You want to pay special attention to two areas:

• Pass Record Object-Type Code and Unique Identifier as Parameters

• Restrict Cross-Frame Scripting

The first option (Pass Record Object-Type Code and Unique Identifier as Parameters) is actually six parameters in Microsoft Dynamics CRM 4.0 (only two in the previous version):

The typename is the name of the entity (Account, Contact, and so on). For custom entities, the customization prefix is prepended (normally new_; but if you’ve changed the customization prefix, which is always a good practice, that will be your prefix, followed by the entity name. For example, if we create a new entity called ProjectDescriptions, the typename will equal new_ProjectDescriptions or wf_ProjectDescriptions).

The type is an integer that uniquely identifies the entity. Table 1 shows the object codes for CRM.

The id is the ObjectId, which is the unique identifier or GUID. This value is displayed in the URL of every form in the system (and is null until the form is created).

Figure 2 shows a GUID of a sample account in the address bar.

Figure 2. Microsoft Dynamics CRM GUID sample.

The orgname is the unique name of the organization, the UserLCID is the language code in use by the current user, and the OrgLCID is the language code that represents the base language for the organization.

Both the UserLCID and the OrgLCID are four-digit codes.

Consider this illustration of the effect that passing these parameters has. When the URL referenced in Figure 3.7 is called without Pass Record Object-Type Code and Unique Identifier as Parameters being selected, the following URL is called from the form:

http://www.webfortis.com/clientportal.aspx

When the Pass Record Parameters option is selected, the following URL is called from the form:

http://www.webfortis.com/clientportal.aspx?type=1&typename=account&id={5CA8FBFF-
46E9-DC11-914C-0030485C8E55}&orgname=Webfortis&userlcid=1033&orglcid=1033

					  

The page that is being displayed in the IFrame (in this case, the clientportal.aspx) can easily read the variables using the HttpRequest.QueryString. (If you are using an HTM page, the parameters can be accessing using the window.location.search property in JavaScript.)

Table 1 shows the object codes for CRM.

You can readily see how powerful and easy it is to create specific information related to the selected record on the underlying application using this information.

The second option, Restrict Cross-Frame Scripting, is selected by default to help protect the integrity of the CRM application. The effect of this selection is to basically place the application in the IFrame in restricted mode (as defined in Internet Explorer).

This option is unselected when you want to have a level of interaction between the application that is in the IFrame and CRM.

An example of this is a custom application that performs a background check on an account for credit-worthiness. When the credit check comes back, the custom application could reference a Boolean value on the account form and set the value of Background Check Cleared equal to true.